home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_1199 / 1183 < prev    next >
Internet Message Format  |  1994-08-27  |  11KB
  1. Date: Fri, 29 Jul 94 23:13 CDT
  2. From: ekl@sdf.lonestar.org (Evan K. Langlois)
  3. To: gem-list@world.std.com
  4. Subject: Re:  Gem List
  5. Precedence: bulk
  6.  
  7. ========================================================================
  8. Well, I break my library down into a few seperate .C files and the
  9. programmer can pick which ones he wants.  I'm sure that's what most of us do.
  10. ========================================================================
  11.  
  12. Nope, you put EVERY function in a separate C file, roll the whole thing
  13. into a .a or .lib or what have you, and then whatever functions the
  14. programmer uses will be included by the linker.  The linker includes 
  15. entire .o files, so the programmer doesn't choose, the LINKER chooses.
  16. This requires libraries to have TONS of files.  Makes a MINIX filesystem
  17. very handy, but that is beside the point.
  18.  
  19. ========================================================================
  20. > Ok, then use XAES. We allow you to drag/resize/scroll/close/et
  21. How do you do this?  HOW?  You can't get anything other than WM_TOPPED
  22. messages to background windows under normal TOS.
  23. Oh, but you're replacing parts of AES, aren't you.  Vector-stealing.
  24. Icky.  Isn't the exception stack frame different on the 68030 compared to
  25. the 68000?
  26. ========================================================================
  27.  
  28. Yes, the stack frame is different.   But its not vectors. It's easier.
  29. Make a window with no gadgets.  Now put gem-objects in it.  These
  30. GEM objects can be anything, even user-defs.   When you get a click
  31. event on that GEM object you control the window through wind_set, so
  32. you will NEVER get a WM_CLOSE or WM_FULL message because those
  33. gadgets don't exist.  It will work, but its a pretty major change.
  34. I've thought about it, but its too much of a change from GEM.  It
  35. IS a nice trick though.
  36.  
  37. ========================================================================
  38. A LITTLE?  Are you kidding?  First I'm going to have to decode the file,
  39. then I'm going to have to translate the codes into what gets displayed,
  40. then I'm going to have to figure out where (and in what character space)
  41. to put them into my menus, then I'm going to have to scan my list every
  42. time the user presses a key, and on top of that, I'm probably going to
  43. have to put up with some brain-dead method of figuring out which key is
  44. which because someone wants to use hardware scancodes for the Ctrl-Letter
  45. keys, which makes no sence because it's non-portable.
  46. ========================================================================
  47.  
  48. It isn't non-portable.  You read for the key, and find the portable
  49. "action" that the user assigned.  Actually, the PROGRAM is portable,
  50. but an app-defs file that uses such will NOT be portable, but who
  51. gives a damn?   They don't need to be unless you really think that
  52. you will carry your app-defs file from a US to a German machine.  And
  53. if you require that level of portability, then don't use scan-codes
  54. in your app-defs!  
  55.  
  56. You don't have to scan a list.  Well, you should, but you could use
  57. the key as an index to a table.  Anyway, you are making things hard
  58. on yourself.  Figuring out which key is which?  You don't NEED to.
  59. You just match the key with the action.  Use a table for the alpha
  60. keys, and then a linked list you can search for symbols and shifted
  61. keys and scan-codes.  Just assign a function pointer to each.
  62.  
  63. I'm going to try and use the string in app-defs as a selector :-)
  64. It may not work, but I wanna try :-)
  65.  
  66. ========================================================================
  67. KISS:  Keep It Simple, Stupid.
  68. ========================================================================
  69.  
  70. Well, Simple is not always the fastest, or the best.  Many people will
  71. argue that GFA Basic is simple.  The executables produced rarely run
  72. on my machine at all.
  73.  
  74. ========================================================================
  75. 7. application interface (every appl reads/evaluates, filecontent stored in
  76.    memory once & accessed through cookie, or server routines through
  77.    cookie (cfr. XHDI/PMMU)).
  78. ========================================================================
  79.  
  80. What?  I hate this idea.  Read a file into memory, then stick a pointer
  81. to it (make sure the memory is globally accessable!!) in the cookie jar.
  82. Now every program has to read the cookie jar in supervisor mode to read
  83. the file.  And, you have to reboot to change the file, since the editor
  84. will edit the file, and you have no semaphores for making a clean change
  85. of the cookie jar pointer (other than the quirk that you are in supervisor
  86. mode).   I might go for the shared memory file system, but what the hell
  87. is wrong with reading a file?   Why take up system memory until its needed?
  88. And since you stick it into global/supervisor accessable memory, I bet
  89. that VM programs will really have a tough time swapping it out.  Please,
  90. just don't.   With a fast hard disk and a good filesystem, reading the
  91. file will be just as fast as playing with cookies.
  92.  
  93. ========================================================================
  94. This is hard to tell.  Is it possible to overflow the AES buffer while
  95. you are _not_ waiting for an event?  If you tell evnt_multi that you are
  96. waiting for MU_KEYBD, and then it returns a keyboard event, will the AES
  97. put another keyboard event in the pipe while you are still processing the
  98. last one?
  99. ========================================================================
  100.  
  101. In single-Tos, no, I don't think so.  At least it would be tough, and
  102. you'd need a pretty poor program.  Considering how fast the average
  103. person can type, a computer sees that as an occasional press that takes
  104. a couple years.  A few hundred thousand to a few million cycles between
  105. key presses?!?   In MultiTOS, the polling and the fact that the AES
  106. actually reads keys while your doing other code can maybe overflow the
  107. buffer.  But in single-Tos, the AES doesn't even get any time to read
  108. a character for you until you call an AES function.  So, if there is
  109. a key waiting for the app to read, the AES won't read another, and the
  110. codes wait around in that huge 128 byte keyboard buffer.
  111.  
  112. And its not really a pipe, but a buffer area.  Then again, I guess a pipe
  113. really is just a buffer, but message buffer or event queue is less confusing
  114. now that MiNT has real pipes.
  115.  
  116. ========================================================================
  117. He probably means things like image scaling, or multithreading (one
  118. thing you mentioned).  Most users have no need of such, he
  119. believes, and I agree.
  120. ========================================================================
  121.  
  122. Of course a USER doesn't have a need for these.  But a user would like
  123. to see icons the proper size in various resolutions, and would like to
  124. have the system fast and responsive, even when doing full-speed serial
  125. IO.  There is no way to keep an event-driven program and still do
  126. serial IO unless you use multithreading, and even then, you'll need to
  127. fire off some timers now and then to do window updates if you don't get
  128. any other events.  Solutions that check the AES, then check the modem,
  129. and back in a tight loop not only waste CPU time, but you now have
  130. polling and the program isn't really event-driven.
  131.  
  132. ========================================================================
  133. The menu bar works the same way in every application, and always has the
  134. same first entry "Desk".  Most applications use "File" and "Edit" as
  135. ========================================================================
  136.  
  137. Slight change .. Desk should now be the name of your application.
  138. Desk is reserved for the desktop.  Once programs comply, you can figure
  139. out what program the menu bar is for (they are supposed to be nearly
  140. identicle right?) by glancing at the menu bar.
  141.  
  142. ========================================================================
  143. > Confirm on Exit/Save on Exit
  144. > Auto Save Prefs on Exit
  145. Say, the user wants those two on one program, and doesn't want both of those
  146. or just one of those on another program.  To overcome this, he would have
  147. to change the configuration each time he ran the program.  You catch what
  148. I'm trying to say?  This means that he would have to CONFIGURE the program
  149. before he could